Carlos Garnacho [Mon, 18 Sep 2023 20:04:32 +0000 (22:04 +0200)]
gdk/wayland: Use toplevel surface for activation
At the moment of launching/activating an application, the
keyboard focus may be on a transient surface that quickly
disappears after activation. If this happens, and the
compositor handles surface destruction before the activated
application gets to reply, the activation request may be
deemed outdated, and the "demands attention" paths be taken.
Peek the toplevel from the focus surface, as that has larger
guarantees to remain valid for the whole duration of the
operation.
Carlos Garnacho [Mon, 18 Sep 2023 17:42:41 +0000 (19:42 +0200)]
gtkwindow: Pick a suitable widget to continue the implicit grab
When a widget in the GtkPointerFocus stack becomes insensitive, we've
so far broken the implicit grab entirely. This has the side effect of
breaking accounting of the active state on the widgets that are
ancestors of the widget that became insensitive.
The easiest, and most consistent thing to do (i.e. giving widgets
in the GtkPointerFocus stack certain level of isolation wrt state
changes in other widgets) is to transfer the implicit grab to the
topmost actor of the GtkPointerFocus stack that can keep handling
events.
This fixes the unbalanced accounting of active state on ancestors
of widgets becoming insensitive, and avoids thorny questions about
how to handle implicit active state with broken implicit grabs.
Carlos Garnacho [Mon, 18 Sep 2023 17:40:05 +0000 (19:40 +0200)]
gtkwindow: Clear active state on sensitiveness changes
When altering the broken implicit grab due to sensitiveness changes,
also ensure to clear the active state from the affected actors. This
fixes unbalanced implicit active state accounting on the widgets going
insensitive.
Sergey Bugaev [Fri, 25 Aug 2023 16:13:43 +0000 (19:13 +0300)]
colorbutton, fontbutton: Propagate focus-on-click to inner buttons
These widgets wrap a GtkButton internally. Make it possible to prevent
the inner button from grabbing focus on click by propagating the value
of the focus-on-click property from the widget to the inner button.
Benjamin Otte [Mon, 18 Sep 2023 05:48:10 +0000 (07:48 +0200)]
gsk: Fix clipping error when drawing shadows
When shadows were offset - in particular when offset so the original
source was out of bounds of the result - the drawing code would create a
pattern for it that didn't include enough of it to compose a shadow.
Fix that by not creating those patterns anymore, but instead drawing the
source (potentially multiple times) at the required offsets.
While that does more drawing, it simplifies the shadow node draw code,
and that's the primary goal of the Cairo rendering.
This function is deprecated, but we should still document it properly.
It appends, not prepends. This is clear enough from its implementation,
but also we have practical experience with WebKit in:
https://github.com/WebKit/WebKit/pull/8663
Matthias prefers to avoid the prepend, append, start, and end
terminology altogether.
Benjamin Otte [Thu, 7 Sep 2023 14:02:09 +0000 (16:02 +0200)]
rendernode: Fix Cairo rendering of repeating gradients
Cairo and the GL renderer have a different idea of how to handle
transitioning of colors outside the defined range.
Consider these stops:
black 50%, white 50%
What color is at 0%?
Cairo would transition between the last and first stop, ie it'd do a
white-to-black transition and end up at rgb(0.5,0.5,0.5) at 0%.
GL would behave as it would for non-repeating gradients and use black
for the range [0%..50%] and white for [50%..100%].
The web would rescale the range so the first stop would be at 0% and
the last stop would be at 100%, so this gradient would be illegal.
Considering that it's possible for code to transition between the
different behaviors by adding explicit stops at 0%/100%, I could choose
any method.
So I chose the simplest one, which is what the GL renderer does and
which treats repeating and non-repeating gradients the same.
If the entry has icons, we may end up increasing our minimum and natural
height compared to the values the text child returned. In that case, we
should also adjust the baseline values to account for the text being
shifted down.
centerlayout: Fix measuring in presence of baselines
The measure logic (unlike the allocation logic) was enforcing strict
baseline alignment of child widgets even if no child widget had valign
set to baseline. This was causing GtkCenterLayout to request more size
than it actually needed.
Instead, bring the logic closer to that of GtkBoxLayout by introducing
explicit have_baseline and align_baseline variables. We track and report
baseline if have_baseline gets set, but it only affects our reported
minimum and natural sizes if align_baseline ends up set, which happens
if there's a child widget that has valign set to either one of the two
baseline values, and itself reports a valid baseline.
Matthias Clasen [Tue, 29 Aug 2023 16:18:49 +0000 (12:18 -0400)]
composetable: Warn for things we can't handle
The compose table stores the keyvals to match against
in a guint16 array, so it can't handle directly encoded
Unicode codepoints (which have a high bit set). Warn
if we encounter those.
Matthias Clasen [Tue, 29 Aug 2023 16:56:25 +0000 (12:56 -0400)]
gsk: Clean up standalone headers
We require folks to include gskglrenderer.h in order
to create a GL renderer. So we be careful to only
include header in gskglrenderer.h that won't trigger
ugly warnings.
Michael Orlitzky [Mon, 28 Aug 2023 19:27:46 +0000 (15:27 -0400)]
testsuite/gsk: add explicit dimensions to <svg> elements
Without an explicit width, height, and viewBox, there is no single
correct way to render an SVG. In the absense of said information,
librsvg is capable of making a guess by rendering the SVG to a Cairo
surface and then analyzing that surface; however, this process is
merely heuristic.
There are three GTK tests for SVG images that are missing dimensions.
While this is not a violation of the SVG specification, it does
implicitly couple the test to the librsvg rendering heuristic. In this
commit we add that dimension information so that the expected result
is unambiguous.
Sergey Bugaev [Wed, 23 Aug 2023 15:13:16 +0000 (18:13 +0300)]
snapshot, gsktransform: Mention that rotation happens around (0, 0)
...and not around the center of the render node, as one could expect
given that the render node syntax for rotation, transform: rotate(90);,
happens to match the CSS syntax for the same thing, and CSS does rotate
around the center by default.
Sergey Bugaev [Wed, 23 Aug 2023 14:39:44 +0000 (17:39 +0300)]
snapshot: Fix push_repeat () with empty child bounds
The logic would confuse empty child bounds (in which case nothing should
get rendered) with NULL child bounds (in which case the child node's own
bounds should get used). In fact, if the child bounds are empty, we can
discard the descendant render nodes completely, getting a nice little
optimization.
It's expected that gtk_widget_get_root() will return NULL if the widget
tree does not contain a root widget. I don't know what that means or why
it happens, but it's true in gnome-control-center's network panel when
displaying the OpenVPN configuration dialog. We need to handle it.
projects / gtk4.git / log